A Method of Configuring a Product 



Field of the Invention 

The present invention generally relates to the task of configuring a product composed of several parts. The 
parts have inter-dependencies and as a consequence there are certain requirements regarding selection of 
the parts in order to build a working product. Generally, the process of determining whether a collection of 
parts will work together is a complex task and a computer program is often used to help solving this task. 
Such a computer program must work with the inter-dependencies in an efficient yet precise manner. This 
invention is related to how an implementation can be made of such a computer program. 

Background of the Invention 

The invention relates to a method for performing a computer assisted product configuration. 

A complex product is composed of several components. A product model of a complex product is of- 
ten made by looking at the product as being composed of several generic components. For each of these 
components there is a group of specific alternatives. 

An example of a product model of a bike is: A bike is build of the following components: a frame, a front 
wheel, a rear wheel and a gear set. The following alternatives for the frame component exists: carbon male, 
standard female, standard male, off-road. For the front wheel component: slick, off-road. For the rear wheel 
component: slick, off-road. And, finally, for the gear component: internal three speed, external 10 speed. 

In the context of configuration the word "component" is not to be understood only as the generic description 
of a physical component. It could also be attributes such as colour and shape, parameters such as number 
of gears and horsepower. A component could also be understood as "need attributes", which express a need 
from the user of the configurator rather than a property of the product, such as the type of a bicycle (off-road, 
city bike, heavy duty bike etc.), the taste of a user (fashionable, classic, childish), or the price or weight or 
similar properties of interest for a user of a product. 

A specific alternative must be selected for each of the components to build the complex product. A number 
of selections is called a partial configuration of the product. The complete selection of an alternative for 
each component is called a complete configuration (or just a configuration) of the product. 

The number of possible configurations of the product grows rapidly with the number of components the 
product is composed of. For example, to configure the example bike, one must select among four frames, 
two front wheels, two rear wheels and two gears. Thus there exists 4x2x2x2 = 32 different configurations. 
In realistic examples, this number quickly grows beyond millions. 

Due to incompatibilities, etc., all combinations of the alternatives will not work. If we consider the bike ex- 
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ample, it might be the case that the front and the rear wheel must be of the same type. Another requirement 
could be that the carbon male frame is the only frame allowing the external 10 speed gear. The descrip- 
tions of these incompatibilities between the alternatives are called the product requirements. The product 
requirements are often expressed as rules defining compatibilities between components. A configuration is 
said to be consistent if all requirements are satisfied. For the bike example, there are 10 different consistent 
configurations (8 configurations with an internal three speed gear and 2 configurations with an external 10 
speed gear) out of the 32 possibilities. 

In general, the requirements can be complicated and hard to overview for a human, and it is a complex task 
to determine a consistent configuration. A computer program can be of great help during the configuration 
process and generally works by checking a user's selections against the rules. This checking is generally 
hard to perform: either the checking may take unreasonable long time or the results of the checks may be 
imprecise. There are at least two different ways of treating the rules. 

Explicit Enumeration This method typically uses bit-vectors to represent all possible consistent configura- 
tions. All possible configurations are tested against the rules and the configurations that turns out to be 
consistent are enumerated in a list, typically using a hash-table of bit- vectors. One key limit with this 
approach is that the number of configurations grow rapidly when the number of available components 
rises (typically, the number of configurations grows exponentially with the number of components). 
This means that the amount of memory which is required is extremely large and the method is not ap- 
plicable to large product models. Another problem is that even if the number of configurations is small 
enough to be kept in memory, the algorithms need to traverse and treat each possible configuration 
independently yielding running times that are linear in the number of configurations. 

Rule/Constraint Propagation When a configuration selection is made, the rule database is searched in 
order to check for consistency. The search time is unpredictable and therefore often limits are imposed 
on the allowed time consumption in order to ensure a timely response to the user. In order to meet 
the time limit, the search must often be ended prematurely without the full and correct result being 
known. The search is based on the accumulation of information by repeatedly applying the rules 
from the rule base to the selections that have been made. This is often very costly. Furthermore, the 
search time, and thus the quality of the search, is highly dependent on exactly how the rules have been 
formulated. 

State-of-the-art tools apply the two techniques described above. They have been developed as sales assistant 
tools and are now being adapted to the Internet. On the Internet there is no human sales assistant available to 
compensate for inaccuracies and lack of information. The user is going to execute the whole sales process 
himself, which imposes hard requirements on the quality of the sales system. The system must have a fast 
response time and ensure that the results are still accurate. For example, it must never be the case that the 
user is lead to select an alternative that is inconsistent (i.e., some of the rules become violated) with the 
user's earlier selections. 



State-of-the-art tools have difficulties obtaining precise results and at the same time ensuring desirable re- 
sponse times (while dealing with complex products and allowing the system to handle many concurrent 
users.) 

A number of patents are related to product configuration. 

5 US 6,1 15,547 discloses a product configuration comprising a specific way of caching earlier configurations 
improving performance of a configuration program. 

US 5,675,784 discloses a product configuration comprising a data structure (a "three tiered hierarchical data 
structure") to be used for modelling products. 

EP 077023 9B1 discloses a product configuration comprising an expert system. This configuration method 
10 is related to rule/constraint propagation. 

US 5,206,949 discloses a product configuration comprising a database search and retrieval system. 

US 5,844,554 discloses a product configuration comprising a graphical user interface method for designing 
the product model. 

US 5,987,473 discloses a product configuration comprising a method for performing interactive configura- 
15 tion via a network. 

US 5,995,979 discloses a product configuration comprising a method for allowing a user to select an entry 
in a database over a network. 

US 5,996,1 14 discloses a product configuration comprising a method for handling the many possible con- 
figurations. This configuration method is related to Explicit Enumeration. 

20 US 5,745,765 discloses a product configuration comprising a method for allowing a user to select a consis- 
tent configuration. 

The invention described in this patent applies a known technique symbolic model checking known from for- 
mal verification of hardware circuits to solve the computational problems inherent in developing a program 
for computer assisted configuration. Symbolic Model Checking is described in [K.L. McMillan Symbolic 
25 Model Checking: An Approach to the State Explosion Problem]. 

Summary of the Invention 

Thus, in a first aspect, the invention relates to a method of configuring a product comprising a number of 
components, the method comprising: 

• providing, for each component, information relating to a group of alternatives for the component, 
30 • defining rules relating to compatibilities between alternatives from different components, 
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• representing the rules in a Directed Acyclic Graph (DAG), and 

• iteratively configuring the product by repeatedly: 

- choosing a component, 

- selecting an alternative from this component's group of alternatives, 

s - checking the DAG whether the alternative selected is compatible with other chosen alternatives 

from other components. 

In the present context, a component is not to be understood only as the generic description of a physical 
component. It could also be attributes such as colour and shape, parameters such as number of gears and 
horsepower. A component could also be understood as "need attributes", which express a need from the user 
10 of the configurator rather than a property of the product, such as the type of a bicycle (off-road, city bike, 
heavy duty bike etc.), the taste of a user (fashionable, classic, childish), or the price or weight or similar 
properties of interest for a user of a product. 

A rule may relate to the compatibility of an alternative from e.g. two different components of the product. 
However, it may be preferred that the rule relates to compatibility of an alternative from a larger number of 
15 components. In an extreme, but in no way unthinkable, is a rule which relates to a product comprising an 
alternative from each of the components. 

Naturally, the information relating to an alternative or a group of alternatives may be information relating 
to similarities or differences thereof. Normally, this information will be information relevant vis-a-vis the 
other components and/or the alternatives of the other components. 

20 When having represented the rules in the DAG, it is no longer necessary to check the (normally very large 
number of) rules. Instead, the DAG may be traversed, analysed or even amended in accordance with infor- 
mation relating to selected/chosen alternatives. This procedure may be made much faster than the individual 
checking of a number of rules. 

In the present context, an alternative is "chosen" if it has been "selected" and found to be part of the com- 
25 bined product which is sought configured - that is, normally, when the selected alternative has been found 
to be compatible with at least one chosen alternative. 

The iterative configuring may be ended when an alternative is chosen for each component and preferably 
when the chosen alternatives of the components are compatible. 

It may be desired to, before the selecting of an alternative, use the DAG to determine, for at least one of 
30 the components, a subset of alternatives for the component, so that each of the alternatives in the subset is 
compatible with the other chosen alternatives from the other components, and providing this information to 
a user. 

In this situation, the user may desire information relating to the compatibility with a number of alternatives 
for a given component - compatibility with the alternatives already chosen - in order to, normally, select a 
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compatible alternative from that group. This subset may relate to preferences of the user, such as dimensions, 
colours, manufacturer, place of manufacture, etc. 

In may ease the interaction with the system if the information to the user is provided as computer generated 
speech. This is done by providing a system with a speech synthesizer and the providing of information to a 
5 user further comprises 

• providing the information by speech generated by the speech synthesizer. 

Alternatively, the steps of selecting a component and an alternative may further comprise, for each of the 
components: 

• using the DAG to check which of the alternatives of the component that are compatible with at least 
10 one of the chosen alternatives of each of the other components (i.e. those for which alternatives have 

been chosen), 

• providing a user with this information, 

• allowing the user to select one of the alternatives that were compatible with at least one of each of the 
other component's chosen alternatives. 

15 Thus, in this manner, information is provided relating to the compatibility of all alternatives for the com- 
ponent - with the alternatives already chosen, in order for the user to quickly be able to progress in the 
configuring of the product. 

However, it may, instead or in addition, be desired that the steps of selecting an alternative and checking the 
DAG further comprise the steps of: 

20 • selecting or defining a subgroup of alternatives to the chosen component, 

• checking the DAG for which of the alternatives in the subgroup that are compatible with chosen 
alternatives from other components, and 

• providing information relating to which of the alternatives in the subgroup are compatible with chosen 
alternatives of other components. 

25 One situation where this may be convenient is the situation where the user has not yet decided on a specific 
alternative, but he provides a subgroup of alternatives that are checked for compatibility with chosen alter- 
natives of other components. This information can be used to further guide the user during configuration. 

Another approach that can be beneficial is to: 

• at least once, defining information relating to limiting the alternatives of at least one of the compo- 
30 nents, and 



5 



• checking the DAG for which of the alternatives of the components is compatible with the limiting 
information. 

This limiting information may be provided by a user, and information relating to which of the alternatives 
of the components are compatible with the limiting information may be provided to the user. 

5 Such limiting information may be information relating to compatibilities between alternatives from different 
groups desired by the user. 

The iterative configuring may also be ended upon request from a user, normally at a point therein where there 
has not been chosen/selected an alternative for each component, or where the alternatives selected/chosen 
are not fully compatible. Then, information may be provided relating to all possible compatible products 
10 comprising at least one chosen alternative for each of the products for which an alternative has been chosen 
- and this information may be provided to the user. 

Thus, the user may end the configuration and then be informed of the total number of compatible products 
available comprising the alternatives chosen. 

Also, the iterative configuring may comprise the step of obtaining the number of all possible compatible 
15 products comprising at least one chosen alternative for each of the products for which an alternative is 
chosen and providing this information to the user. In this manner, the user may be constantly informed of 
the number of products available comprising the alternatives chosen. It should be noted that the user will 
be able to actually select or choose more than one alternative for a given component. In this situation, the 
compatibility check will be that of each such alternative and the total number of potential final products will 
20 relate to the sum of potential final products comprising one of those alternatives. 

In general, the step of representing the rules in a DAG may comprise representing the rules in a graph 
comprising: 

• at least one terminal node, 

• a plurality of nodes comprising: 

25 — a mathematical expression having a plurality of possible disjoint outcomes and 

- a number of pointers corresponding to the number of possible outcomes of the expression, 

wherein: 

• a pointer of at least one of the nodes points to another of the nodes, and 

• a pointer of at least one of the nodes points to one of the at least one terminal node, 

30 • at least one of the nodes being a top-most node from which one or more paths are defined from a 
top-most node to one of the at least one terminal node via one or more of the nodes and the pointers 
thereof, each node being part of at least one path. 
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This is a standard manner of representing rules in a DAG. Thus, the rules are represented as mathematical 
formula and are introduced into one or more nodes. Each rule comprises one or more outcomes — and the 
pointers of the nodes each relates to such an outcome. Thus, different outcomes of the rules will provide the 
traversing of different paths through the graph/DAG. 

5 Thus, the step of representing the rules in the DAG may comprise providing one or more of the nodes with 
mathematical expressions each comprising a mathematical operator, each operator describing how the rules 
represented by the nodes pointed to by the pointers of the pertaining node are to be combined in order to 
represent the combined set of rules. 

The step of representing the rules in the DAG may comprise representing the rules in a graph comprising a 
10 number of the nodes, the mathematical expression of which is a Boolean expression and/or a variable. 

Also, the step of representing the rules in the DAG may comprise representing the rales in a graph compris- 
ing nodes, the mathematical expressions of which are ordered according to a given ordering such that, for 
each node, the expression of an actual node is of a lower order than the expressions of any nodes pointed to 
by the pointers of the actual node. 

is Providing an ordering facilitates a number of operations on the DAG, such as searching in a DAG and 
combining two DAGs. 

In order to maintain a suitable DAG, the representing of the rules in the DAG may further comprise the steps 
of: 

• identifying a first and a second node having the same expression and the pointers of which point to 
20 the same nodes, and 

• having pointers pointing to the first node point to the second node. 

In that situation, two nodes actually representing the same contents are reduced to only one. 

A preferred manner of providing the DAG is one wherein the step of representing the rules the DAG com- 
prises: 

25 • representing each rule as a logical expression, 

• from each logical formula constructing a partial DAG representing the set of possible solutions to the 
formula, 

• constructing the DAG representing all the rules from the partial DAGs representing each of the logical 
formulas. 

30 This method is rather simple in that the constructing of a partial DAG from a rule is normally a simple task - 
and the combination of DAGs is a well-known technique, which is, actually, facilitated if the above ordering 
of the expressions is used. 
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Preferably, the step of providing the information relating to the alternatives for each component comprises: 

• selecting Boolean variables for representing the individual alternatives of the component, 

• providing an encoding for each of the alternatives of the component as a combination of Boolean 
values for the Boolean variables. 

5 Then the step of representing each rule as a logical formula/expression may comprise providing the Boolean 
variables relating to the alternatives to which the rule relates and interrelating the variables in accordance 
with the rule. 

In general, the step of representing the rules in the DAG preferably comprises providing at least one type of 
terminal node and wherein, for each path comprising a such terminal node, the combination of all expres- 
10 sions and all pertaining outcomes relating to the pointers of the path relate to either compatible products or 
non-compatible products. 

It is clear from the above that the variables of the mathematical expressions of the nodes of a path relate to 
a number of alternatives of components. It is also clear that the path is also defined by the pointers linking 
the nodes together and that those pointers each relate to an outcome of a mathematical expression - and 
15 thereby to a given relation between variables. Thus, the information of a path - including the information 
of the terminal node - preferably provides information as to a product, the alternatives thereof and the 
compatibility therebetween. 

Preferably, the step of representing the rules in the DAG comprises providing a first and a second type of 
terminal nodes and wherein: 

20 • for each path comprising a terminal node of the first type, the combination of all expressions and all 
pertaining outcomes relating to the pointers of the path relate to a compatible product, and 

• for each path comprising a terminal node of the second type, the combination of all expressions and 
all pertaining outcomes relating to the pointers of the path relate to a non-compatible product. 

In this situation, the first type of terminal node may be adapted to represent "true", "one" or "1", and the 
25 second type of terminal node may be adapted to represent "false", "zero" or "0". 

In general, the step of selecting an alternative may comprise identifying Boolean variables relating to any 
other alternative(s) of the component and nodes comprising expressions relating to such other alternative(s) 
and, in the DAG, identifying paths comprising such nodes and altering any terminal node(s) thereof of the 
first type to terminal node(s) of the second type. Thus, such paths then may relate directly to "incompatible 
30 products" in that these products are no longer interesting - the selected alternative normally not being com- 
patible with the other alternatives for the same component. If the user selects a subgroup of alternatives for 
that component, the same procedure is, naturally, followed as to those alternatives of the component which 
are not in the subgroup. 
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In this situation, the computing of the number of possibilities of different choices may be performed by the 
following steps applied to the DAG and for each top-most node: 

• starting from the topmost node and iteratively finding the number of possibilities represented by the 
actual node, by performing the steps of: 

5 - if the node is a terminal node, providing a "1" if the terminal node is of the first type and a "0" 

if it is of the second type, 
- else: finding the number of possibilities represented by each node pointed to by a pointer of the 
actual node, and therefrom computing the number of possibilities represented by the node. 

Normally, the number of possibilities represented by a node having, for example, a first number of possibil- 
10 ities represented by one pointer and a second number of possibilities by another pointer can be computed as 
the sum of the first number of possibilites and the second number of possibilites. However, if, due to a size 
reduction of the DAG (such as "local reduction"), implicit nodes are placed (implicitly) between the actual 
node and the node(s) pointed to by the first and/or second node(s) these implicite nodes must be taken into 
account when finding the number of possibilites represented by the actual node. 

15 If, during configuration, a selected alternative is not compatible with other, chosen alternatives, the step of 
checking the DAG may further comprise, 

• providing information relating to other chosen alternatives which are not compatible with the selected 
alternative, and 

• providing this information to a user. 

20 In this situation, the user may choose to actually enter or choose/select the selected alternative and then 
un-choose the or those alternative(s) which is/are not compatible therewith. 

A number of manners exist for actually providing the rules relating to the compatibilities. A preferred 
manner is one where at least one of the rules is defined by 

• obtaining, by querying a database, information relating to alternatives relating of one or more com- 
25 ponents and/or information relating to compatibility between two or more alternatives to different 

components, and 

• building one or more rules from the information obtained from the database. 

A simple manner of performing this is one wherein the database comprises a two-dimensional table having, 
in each of a plurality of rows thereof, information relating to a product comprising an alternative from each 
30 component, the alternatives being compatible, wherein the step of providing a rule comprises providing 
a rule relating to the information of each row and wherein the step of representing the rules in the DAG 
comprises providing a disjunction of the rules. 
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Thus, each row of the table comprises information relating to a full product comprising an alternative for 
each component and where all alternatives of each product are fully inter-compatible. The information of a 
single row may easily be provided as a single rule which is subsequently introduced in the DAG. 

This has the advantage seen from the side of the entity providing the product configured that, as the rules 
relate only to a predetermined range of identified products, only those products may be configured. Thus, 
even though it seems, from the side of a user performing the configuration, that the configuration is not 
limited by anything but the compatibilities, the configuration will always end in a product which is identified 
by the supplyer. 

Preferably, the step of checking the DAG whether a selected alternative is compatible with the chosen 
alternatives comprises searching the DAG for a path from a topmost node to a terminal node, the search 
comprising: 

• starting with the top-most node as an actual node, 

• iteratively, until the actual node is a terminal node: 

- evaluating the mathematical expression in the actual node and determining the outcome thereof 
in view of the alternatives chosen from other components, 

- selecting the pointer of the node representing the outcome, 

- selecting, as the actual node, the node pointed to by the selected pointer. 

• providing information relating to the chosen alternatives, and 

• the information relating to the path represents that the choices are compatible. 

One simple manner of providing information from a path in the DAG is one providing, from the expressions 
of the nodes of the path, information relating to which alternative(s) of a given component has/have been 
chosen, and the information of compatibility of the product comprising those alternatives is given by the 
representation of the terminal node of the path. 

Thus, the information relating to the individual alternatives is derived from the expressions of the nodes and 
the pointers interconnecting the nodes - and the compatibility information is seen in the terminal node of the 
path. 

Thus preferably, the expressions related to nodes of the DAG are Boolean variables, the terminal nodes 
represent either "true"or "false", a path comprises one or more nodes each comprising a mathematical 
expression and a pointer to another node or the terminal node in the path, the information of the path relating 
to the identities of the variables in the mathematical expression(s) of the node(s) of the path and values or 
dependencies thereof, the identities and values/dependencies relating to chosen alternatives of components, 
the chosen components being compatible if the terminal node of the path represents "true" and the chosen 
components being incompatible if the terminal node of the path represents "false". 
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A special situation exists where a component may be of a type which, naturally, has to be taken into ac- 
count during the configuration but which may not be informative or relevant to e.g. a user performing the 
configuration. Thus, it may be desired to "hide" such components during the configuration. 

An example of a component which may be hided is the width of the hub of a bicycle wheel. This width is 
very important in that it describes the compatibility of a frame and a wheel, but a user configuring a bicycle 
does not need to pay interest to this point. The system may simply hide this component and make sure that 
the user is not able to perform selections which are contrary to an implicitely selected hub width (such as 
defined by an already chosen frame or wheel). 

In that situation, the step of representing the rules in the DAG may comprise: 

• representing the rules in an actual DAG, 

• selecting at least one of the components to be hidden, 

• changing the actual DAG by: 

- identifying nodes in the actual DAG comprising expressions relating to the selected compo- 
nents), 

- removing these nodes from the actual DAG, 

- adding nodes, not comprising expressions relating to the selected component(s), to the actual 
DAG so that the compatibilities implied by these component(s) are reflected by the actual DAG, 

• providing the actual DAG as the DAG representing the rules. 

Thus, the DAG is simply altered in a manner so that an alternative of a hidden component which implicitely 
selects alternatives for other component will implicitely select these alternatives for the other components in 
a way so that subsequent compatibility checks will relate also to the "hidden" component even though the 
user will not be able to verify this. 

It is preferred to modify the DAG by as early as possible removing the "hidden" components. This may be 
done by: 

• for each of the rules, constructing a partial DAG representing the rule, 

• identifying at least one of the components to be hidden, 

• selecting an ordering of the identified components, 

• initially constructing an actual DAG representing no rules and then repeatedly, 

- selecting a non-selected component of lowest order, 

- repeatedly, until all partial DAGs comprising expressions relating to the selected component 
have been chosen: 
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* choosing a partial DAG comprising expressions relating to the selected component, 

* combining the actual DAG with the chosen partial DAG into a new actual DAG, 

- changing the actual DAG by: 

* identifying nodes in the actual DAG comprising expressions relating to the identified com- 
ponent, 

* removing these nodes from the actual DAG, 

* adding nodes, not comprising expressions relating to the identified component, to the actual 
DAG so that the compatibilities implied by the identified component are reflected by the 
actual DAG, 

• providing the DAG by combining the actual DAG with all non-chosen partial DAGs. 
In general, the method may further comprise: 

• identifying a user, 

• performing the step of selecting an alternative of a component by the user through communication 
between a device controlled by the user and another device where the iterative configuration is per- 
formed, 

• transmitting information relating to the checking of the DAG to the user. 

Thus, the main part of the computational load - that is the deriving of the rules and of the DAG as well as the 
iterative checking of the DAG - is performed remotely from the user and only the results are transmitted to 
the user. This saves bandwidth on e.g. the Internet where such configuration may be performed on virtually 
any type of product. 

Also, the method may further comprise: 

• identifying a user, 

• prior to the iterative configuring: 

- transmitting the DAG to a device controlled by the user, 

- performing the iterative configuring on the user's device. 

In this manner, the DAG is transmitted to the user which then performs the configuration on the DAG on the 
client - that is on a computer controlled or maybe even owned by the user. 

An especially prefered embodiment is one comprising the step of, during the iterative configuration,: 

• obtaining information relating to one or more alternatives for components for which no alternatives 
have been chosen, each of the one or more alternatives being compatible with the chosen alternatives, 
and 
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• providing the user with this information. 

Thus, as only reasonable alternatives are displayed, whereby the configuring may be performed much faster 
and without the user making mistakes by attempting to combine incompatible alternatives. 

A beneficial way for a user to interact with the product configuration is when the method further comprises 
providing a system with a speech recognizer, and wherein the step of iteratively configuring the product 
farther comprises 

• choosing a component from a text recognized by the speech recognizer, and 

• selecting an alternative from this component's group of alternatives from a text recognized by the 
speech recognizer. 

In this manner, alternatives are selected by speech, which in applications such as product configuration over 
a telephone is highly preferred. 

In applications where the product to be configured is a device, it is beneficial if the method further comprises 
identifying a configurable device and an interface device, and 

• storing the DAG representing the rules on the configurable device, 

• uploading the DAG from the configurable device to the interface device, and 

• in the step of iteratively configuring the product, performing the checking of the DAG whether the al- 
ternative selected is compatible with other chosen alternatives from other components on the interface 
device. 

In this manner, all information relating to the configuration of the configurable device, can be stored within 
the device and accessed from any interface device without the interface device having specific knowledge 
about the configurable device. 

In situations where some of the alternatives can be determined by the configurable device itself, it is ben- 
eficial if the method further comprises identifying a list of predetermined components in the configurable 
device and identifying a list of predetermined alternatives for these components in the configurable device, 
and wherein the step of iteratively configuring the product further comprises 

• performing the checking of the DAG whether the alternative selected is compatible with other cho- 
sen alternatives from other components and compatible with the predetermined alternatives on the 
interface device. 

The predetermined alternatives makes it easier for the user, since fewer choices of alternatives have to be 
made. 
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In the product configuration of many products, it is beneficial to observe that some of the components are 
observer components for which the user will not choose an alternative but only be interested in what the 
compatible values are. This can be exploited if the method further comprises identifying a list of observer 
components and a list of non-observer components, and 

• representing the rules for the non-observer components in a DAG, 

• determining, for each observer component, a subset of the rules, such that from these rules it is 
possible to determine the alternatives for the observer component that are compatible with alternatives 
for the non-observer components, 

• representing for each observer component the subset of rules as an observer DAG, and 

• in the step of iteratively configuring the product 

- checking the DAG whether the alternative selected is compatible with other chosen alternatives 
from other components, 

- determining a set of system determined alternatives by determining for each component whether 
there is only a single alternative compatible with all the chosen alternatives, 

- for at least one of the observer components, checking the observer DAG for the observer com- 
ponent to determine whether there is only a single alternative compatible with other chosen 
alternatives and the set of system determined alternatives, and 

- providing this information to a user. 

Representing the rules in different DAGs is advantageous, because it decreases the total size of the DAGs 
providing the benefits of requiring less storage and increasing performance. 

Further useful information can be given to the user if the step of iteratively configuring the product further 
comprises 

• for each pair of component and alternative providing a classification of the state of the pair, 

• adopting the classification to one of a list of outcomes comprising blocked, selectable, user selected, 
system selected, or forceable, 

• providing a classification of blocked when the alternative cannot be chosen for the component even 
without considering choices of alternatives for other components, 

• providing a classification of selectable when the alternative for the component is compatible with the 
chosen alternatives from the other components, 

• providing a classification of user selected when the alternative has already been chosen for the com- 
ponent, 
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• providing a classification of system selected when the alternative is the only choice for the component 
that is compatible with the chosen alternatives from the other components, 

• providing a classification of forceable when the alternative can be chosen for the component but is 
incompatible with some of the other choices of alternatives of the other components, and 

• providing information on the classification to a user. 

The classification can be used in the user interface by providing useful information to the user about the 
effect of possible choices of alternatives. Some are impossible, some are directly selectable, others have 
already been selected by the user or the system, and finally some are forceable, meaning that they can be 
chosen if the user is prepared to undo some previous choices. 

A second aspect of the invention relates to a computer program comprising computer program code means 
adapted to perform all the steps of the above method when said program is run on a computer. 

The invention also relates to that computer program embodied on a computer-readable medium and a com- 
puter readable medium comprising the computer program. 

Brief Description of the Drawings 

In the following, a preferred embodiment of the invention will be described in relation to annexes and the 
figures in which: 

Figure 1 shows an overview of the Configuration Process 

Figure 2 shows the creation of the Product Model using Configlt Studio, 

Figure 3 shows Interactive Configuration of a PC, 

Figure 4 shows a PC Example, examplifying a BDD representing the third rule, 

Figure 5 shows another PC Example, examplifying a BDD representing the domain constraints, 

Figure 6 shows another PC Example, examplifying a BDD representing the rales, 

Figure 7 shows another PC Example, examplifying a BDD representing the rules and the domain constraints 
with both public and private variables included, 

Figure 8 shows another PC Example, examplifying the virtual table with a BDD representing the rules and 
the domain constraints, and with only the public variables included, 

Figure 9 shows another PC Example, examplifying a BDD representing consistent configurations under the 
selection of the Seagate-Barracuda-9-9,lGB harddisk, and 

Figure 10 shows show another PC Example, examplifying the virtual table where all variables except X0 
and XI is existentially quantified out. 
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In Annex A the preferred embodiment for the "product description" (an XML document type declaration) 
is given. 

In Annex B, preferred embodiments are given for a number of algorithms: 
Algorithm 1 : Basic BDD operations. 

Algorithm 2: MultiApply. Apply an operator to a set of vertices. 

Algorithm 3: MultiExists. Existentially quantification of a a set of variables. 

Algorithm 4: OrderRules. Order the rules according to the private variables. 

Algorithm 5: ConjoinExists. Conjoin BDDs and existentially quantify variables. 

Algorithm 6: VirtualizeTable. Build a BDD representing a table. 

Algorithm 7: CONFIGl . Restricting a virtual table with respect to a selection. 

Algorithm 8: ConfigConsistent. Restricting a virtual table with respect to a list of selections. 

Algorithm 9: ConfigCheck. Restricting a virtual table with respect to a list of selections, ensuring non- 
emptiness. 

Algorithm 10: ConfigIt. Restricting a virtual table with respect to a list of compatible selections, selecting 
compatible values for the remaining product variables 

Algorithm 1 1 : ConfigCount. Counting the number of consistent configurations in a virtual table. 

Algorithm 12: DetermineDomain. Determine the possible values for a flattened variable in a virtual 
table. 

Algorithm 13: ConfigClient. Interactive Configuration, Client. 
Algorithm 14: ConfigServer. Interactive Configuration, Server. 
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Detailed description of the Drawing 



The invention will be described in terms of a preferred implementation as applied to interactive computer- 
assisted configuration of complex products composed of several parts, this being the origin of the problem 
addressed by the invention. However, it will be understood by those skilled in the art that the invention is 
not limited to this specific application but has a broader scope of application both with respect to the method 
of performing the configuration as well with respect to the structure of the product to be configured. 

The present invention comprises a method for configuring a product. Without limiting the invention a prod- 
uct model is used to model relevant aspects of the product. In the product model the product is composed of 
a number of components, and for each of these components there is a group of alternatives. Each compo- 
nent typically has attributes describing relevant aspects of the component such as colour, behaviour, weight, 
interfaces, etc. For each of these attributes there is a group of concrete values. For example, the colour 
attribute may have the values red, blue or green. Furthermore, there are rules relating to compatibilities 
between alternatives for different components. 

The method for configuring the product comprises: 

• Specifying relevant aspects of the product as the product model. The product model describes com- 
ponents, attributes for these components, as well as alternatives for each component and values for 
each attribute. Furthermore the product model comprises a group of rules relating to compatibilities 
between components and attributes. 

• Encoding this product model as a virtual table representing the consistent configurations of the prod- 
uct model. 

• Configuring the product yielding a consist configuration using the virtual table. Typically this is done 
in an interactive session between a user and a configuration program. 

Figure 1 sketches these steps. The figure shows a specific product (a bike), a specific form for the product 
model (a textual description), a specific virtual table (a Boolean Decision Diagram), and a specific interactive 
configuration process. It is clear to the person skilled in the art that the invention is not limited to these 
specific choices. 

• First a product model of the concrete product, here a bike, is made. This concrete product model 
captures that two different frames exist and two different gears exist. Furthermore, the product model 
captures, by a rule, that if the external gear is chosen, the frame must be a carbon frame. 

• The product model is encoded as a virtual table. The virtual table is a directed acyclic graph that 
represents all consistent configurations. This concrete directed acyclic graph is a Boolean Decision 
Diagram (BDD) (known to the man skilled in the field of symbolic model checking) with two variables 
external (representing that the selected gear is external) and carbon (representing that the carbon 
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frame is selected). Informally, the connection between the BDD and the product model is: If and 
only if an assignment of Boolean values to external and carbon leads to the terminal 1 the 
corresponding configuration is consistent. 

• A computer assisted configuration of the bike is now performed. The computer program shows pos- 
sible alternatives for each component. The user of the computer program selects a component and 
selects one of the possible alternatives for this component. For example, the user can choose the gear 
component, and that the gear should be external. Based on the user's selection the computer program 
uses the virtual table for finding out which subsequent selections that will lead to consistent config- 
urations. For example the computer program will use the virtual table to determine that a selection 
of an external gear implies that the frame must be a carbon frame. This interactive process continues 
until an alternative has been selected for each component. The result of this configuration process is 
a consistent product configuration. 

In the following three sections the product model, the encoding process and the final configuration process 
are further described. In each section, the preferred embodiment is given. 

The Product Model 

Generally, the product model is used to describe what components the product is composed of and the 
inter-dependencies between these components. 

The nature of the invention puts no specific limitation on the product model. Without limiting the invention, 
however, the product model will often define a set of product variables, the domain of each of these variables 
and a set of rules. Each product variable represents a component or an attribute. For a product variable 
representing a component the domain of the product variable corresponds to the possible alternatives for the 
component. For a product variable representing an attribute, the domain of the product variable corresponds 
to the possible values for the attribute. The possible domains of the product variables include the discrete as 
well as the continuous domains. The inter-dependencies between components and attributes are expressed 
as rules and typically formulated as formulas over the product variables. 

An example of a product model is a product model of a computer, composed of a motherboard (three 
different alternatives), a CPU (two alternatives), and a harddisk (two alternatives). Since a CPU is connected 
to a motherboard using a slot, the slot type is an important attribute of both the CPU and the motherboard 
and since a harddisk is connected to a motherboard using a specific controller type, the controller type is 
also an important attribute. The following is a textual example of a computer product model: 

types 

cpu-slot-t = [ SLOT-1 | SLOT-A ] , 
controller-t = [ IDE | SCSI ] 
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variables 

public motherboard: { 
public name: 

5 [ Abit -BX6 -ATX | Aopen-AX6BP-ATX | Aopen-AK-72 -KX13 3 -ATX ] , 

private slot: cpu-slot-t, 
private controller: controller-t 

} 

10 public harddisk: { 
public name: 

[ IBM-DeskStar-25GP-10, 1GB | Seagate-Barracuda-9-9, 1GB ], 
private controller: controller-t 

} 

15 

public cpu: { 

public name: [ Intel-Celeron-A-366MHz | Athlon- AMD- 500 ], 
private slot: cpu-slot-t 

} 

20 

rules 

motherboard. slot=cpu. slot, 

motherboard. controller=harddisk. controller , 

25 motherboard. name=Abit-BX6-ATX => 

motherboard. slot=SLOT-l /\ motherboard. controller=IDE, 

motherboard . name = Aop en - AX 6 B P - ATX = > 
motherboard. slot=SLOT-l /\ motherboard. controller=SCSI, 

30 

motherboard . name=Aopen- AK- 72 - KX133 -ATX = > 
motherboard. slot=SLOT- A /\ motherboard. controller=IDE, 

harddisk. name=IBM-DeskStar-2 5GP- 10, 1GB => harddisk. controller=IDE, 
35 harddisk. name=Seagate-Barracuda-9-9, 1GB => harddisk. controller=SCSI, 
cpu.name=Intel-Celeron-A-366MHz => cpu. slot=SL0T- 1 , 
cpu.name=AMD-Athlon-500 => cpu . slot=SLOT-A 
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The first section declares types that will be used to define the types of product variables. The next section 
declares product variables. These variables each have an identifier and a type. The type system for this 
example comprises atomic constructs as well as record construction ({ . . . }) and enumerated types (. . . | 
... | . . . ). For example, the cpu is a product variable comprising a record consisting of a name and a 
slot, and this slot is of type cpu-slot-t. cpu- slot -t is declared as an enumerated type comprising 
the following two alternatives: SLOT-1 and SLOT-A. The private and public modifiers are used to 
control what components or attributes that are presented to an end-user during configuration (further details 
are given below). The third section declares the rules. These rules are general Boolean formulas over the 
product variables, and all rules must be satisfied for a consistent configuration. Generally, the rules can 
express any relationship between product variables, but the concrete rules presented in this example can be 
thought of as divided into two different categories: 

Attribute rules specifying the value of a certain attribute for a specific alternative. For example we specify 
the slot type of the Aopen-AX6BP-ATX motherboard to be SLOT-1. 

Compatibility rules specifying general inter-dependencies between alternatives/attributes from different 
components. For example we specify that the controller type of the harddisk must be equivalent to 
the controller type of the motherboard. 

In this setup a configuration comprises the selection of a concrete value for all public parts of product vari- 
ables. In the computer example, this comprises the selection of a motherboard name, a CPU name, and a 
harddisk name. A consistent configuration of the computer is a configuration satisfying the rules of the com- 
puter product model. An example of a consistent configuration is the selection of motherboard . name 
to Abit-BX6 -ATX, cpu. name to Intel-Celeron-A-3 66MHz and harddisk .name to 
IBM-Deskstar-2 5GP-10, 1GB. 

In the example above the product model is represented textually. However, the invention is not restricted 
to such a representation. Instead, the complete representation of the product model can be divided between 
multiple representations. An aspect of the invention combines product descriptions with product tables to 
obtain the complete product model. The product description is generally used to capture the structure of the 
product by defining the components and their attributes, and the product tables are generally used to capture 
the concrete alternatives for the components as well as the concrete values for the attributes. 

This approach allows huge tables of product data that normally would be hard to comprehend to be turned 
into a product model for computer assisted configuration. The applications includes the construction of 
a real estate sales shop where it appears to the potential buyer of a house that he "configures" his own 
house. In reality he chooses among for example 10.000 houses using simple drop-down menus presenting 
all consistent choices. In this example attributes include price range, location, garage, swimming pool, 
number of rooms, area, etc. 

The example computer product model can be divided into a product description and three product tables. The 
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product description consists of the same sections as the original computer product model, but the attribute 
rules have been removed: 

types 

cpu-slot-t = [ SLOT-1 | SLOT-A ] , 
controller-t = [ IDE | SCSI ] 

variables 

public motherboard: { 

public name: [ Abit -BX6 -ATX | Aopen-AX6BP-ATX 

| Aopen-AK-72-KX133-ATX ] , 
private slot: cpu-slot-t, 
private controller: controller-t 

} 

public harddisk: { 

public name: [ IBM-DeskStar-25GP- 10 , 1GB 

| Seagate-Barracuda- 9 -9, 1GB ], 
private controller: controller-t 

} 

public cpu: { 

public name: [ Intel-Celeron-A-366MHz | Athlon-AMD-500 ], 
private slot: cpu-slot-t 

} 

rules 

motherboard. slot=cpu. slot, 

motherboard. controller=harddisk. controller 



The first table defines attributes for the motherboard component: 



motherboard . name 


motherboard. slot 


motherboard . cont roller 


Abit -BX6 -ATX 


SLOT-1 


IDE 


open-AX6BP-ATX 


SLOT-1 


SCSI 


Aopen-AK- 72- KX1 3 3 -ATX 


SLOT-A 


IDE 



The second table defines attributes for the harddisk component: 
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harddi sk . name 


harddisk. controller 


IBM-DeskStar-25GP-10, 1GB 


IDE 


Seagate-Barracuda-9-9, 1GB 


SCSI 



The third and last table defines attributes for the cpu component: 



cpu . name 


cpu. slot 


Intel -Celeron-A-3 66MHz 


SLOT-1 


Athlon -AMD- 500 


SLOT-A 



A textual product model can be obtained from a product description and a set of product tables by the 
following method: 

• For each table, translating the table to a rule. 

• Adding the rules obtained in the previous step to the product description. 

The table is translated to a rule using the key observation that a table can be viewed as an expression on 
disjunctive normal form. A table with n rows and m columns is translated as follows: 

• A cell in row i and column j with content in a column labelled yj is translated to an atomic rule 

Vi = 4 

• For a row i among the n rows, all atomic rules obtained from cells on this row are combined by 
conjoining the atomic rules together to form a sub-rule (yi = x\ A ■ • • A y m — x % m ). 

• All n sub-rules are combined by disjoining the sub-rules together to one big rule: 
(yi = x\ A • • • A y m = 4J V ■ • • V (yi = a% A • • • A y m = a*). 

• This one big rule is the table translated to a rule. 

For example, the last table of the computer product model is translated to: 

rules 

(cpu.name=Intel-Celeron-A-366MHz A cpu . slot=SLOT- 1 ) \/ 
(cpu.name=Athlon-AMD-500 A cpu. slot=SLOT-A) 

A convenient extension is to add table filters mapping values in the product table to values in the product 
description. An example of such a filter maps specific prices in the product table (such as $100, $223, 
$817) to price levels in the product description (such as cheap, reasonable and expensive). Such 
a mapping will typically map all prices in a given interval to the same price level. 

The translation to a rule does not need to be performed explicitly. An aspect of the invention is that the 
translation instead can be done on the fly during the construction of the virtual table. 
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Preferred Embodiment of the Product Model 

The preferred embodiment of the product model is composed of a product description and a set of product 
tables. The product description is given as an XML 1 .0 document. The product tables are combinations of 
ODBC data sources and SQL queries. 

The XML document is defined using the document type declaration (DTD) shown in Annex A 10. Basically, 
a product description contains: 

Constant declarations A constant can be specified explicitly (constant), or as an SQL query that when 
evaluated should return exactly one cell dbconstant. 

Type declarations A type declaration (type) basically declares a type identifier as a shorthand for a spe- 
cific type (see below). 

Product Variables A product variable (productvariable) can be declared public or private and is of 
a given a type (see below). 

Rules A rule is a Boolean expression over the product variables that should be satisfied for the configuration 
to be consistent. The expression can either be specified explicitly (rule) or by the use of an SQL 
query that when evaluated should return a table that can be translated to a rule (dbrule). 

Database details Finally, a couple of extra parts of information can be supplied: Alias definitions (alias) 
defines an ODBC data source, SQL query definitions (sqlqueries) and finally, filters (filter) 
that can be used to map between values in the databases and values in the product description. 

The rules comprise structured expression: atomic expressions such as Booleans (true, false), values 
from bounded sub-ranges (0, 1, . . . , n) as well as compound expressions built from arrays, record expres- 
sions and enumeration (sum) expressions. Furthermore, arithmetic and Boolean operators are provided. In 
the preferred embodiment the allowed arithmetic operations include addition, subtraction and multiplication 
and the multiplication operation is only allowed when at least one of the operands is a constant. At first 
the allowed types of arithmetic operators seem odd, but as we shall see later this choice works very well 
together with the preferred embodiment for the virtual table. 

The choice of XML as language for the product description allows for a direct translation to both a textual 
format, as well as a tree data structure for representation on a computer. 

The preferred method for developing the product description is by the use of a graphical user interface. 
ConfigltStudio is such a graphical user interface, see screen-shot in Figure 2. The screen-shot shows the 
ConfigltStudio product model editor, while editing a pc product model. The tree view in the left area of 
the screen-shot is a tree view of the product description and is closely related to the XML document type 
declaration. (On the screen-shot, the term "template" is used for a type declaration and the term "constraint" 
is used for a rule.) The area to the right shows details for the selected vertex in the tree and can be used 
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for manipulating the vertex. The menu on the top of the screen-shot can be used to build (the "Compile" 
menu) a virtual table for the product model (see below) and run a virtual table server (the "Run" menu) for 
interactive configuration over the Internet (see below).- 

Encoding the Product Model as a Virtual Table 

An important aspect of the invention is the process of transforming a product model to a compact and 
efficient representation. This process we refer to as virtual tabulation and the resulting representation we 
call a virtual table. There are many ways in which this transformation can be done. The purpose of the 
transformation is to first find a way of encoding and finding all solutions to the configuration problem and 
then tabulate them virtually in a virtual table such that information relating to the configuration problem 
can be obtained by efficient queries to the virtual table. The encoding involves finding an encoding of the 
components of the product model and a corresponding encoding of the rules. A DAG will represent all the 
rules, such that enquiries about valid solutions to the rules can be performed efficiently. The virtual table 
consists of this DAG and information relating to the relationship between product model and DAG. 

The benefits of the present invention over state-of-the-art comes from the step of using a DAG to represent 
all rules in such a manner that enquiries can efficiently be made as if a table of all solutions were in fact 
present. A full table would most often be too big to be practical, whereas proper chosen encodings can result 
in small DAGs while maintaining the precision by having tabulated all solutions. 

The most vital part of the virtual table is the DAG representing each an every consistent configuration. Since 
there, for a real-life product model, are incredibly many such configurations the DAG must somehow capture 
these configurations in an implicit manner. Still, the DAG must represent exactly these configurations (ie., 
without "loosing precision"). The requirements to the DAG can be divided into two categories: 

Functional requirements The DAG must be able to represent a set of configurations, each of those config- 
uration defining a value for each of the product variables. Basic algorithms on the DAG must mimic 
operations and functions on such configuration-sets: 

• Building the set union and building the set intersection of a group of configuration-sets, building 
the set difference of two configuration-sets, and, changing, restricting or extending the possible 
values of a variable in a configuration-set, etc. 

• Checking for set emptiness, set inclusion and set equivalence. Determining possible values of a 
variable and determining the number of configurations in a configuration set. 

Efficiency requirements The nature/structure of the rules in the product model implies that many of the 
algorithms introduced above will have a typical worst case running time that is (at least) exponential 
in the number of product variables. The size of the DAG will also typically worst case be (at least) 
exponential in the number of product variables. Nevertheless, it must be the case that for real-life 
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product models the algorithms should run efficiently and the DAG representations should be compact. 

These requirements can at first seem hard to fulfill, but it turns out that for real-life product models such 
DAGs in fact exists! 

A Boolean Decision Diagram (BDD) is a DAG comprising nodes each containing a single Boolean variable. 
It is well known from the area of formal verification of hardware circuits that BDDs can be used to encode 
arbitrary Boolean functions of type (where n is the number of Boolean variables): 

B n —5- B. 

These functions are isomorphic to configuration-sets for "Boolean product models." (By a "Boolean product 
model" we think of a product model where the values of the product variables are limited to true and 
false). Therefore, if it is possible to encode general product models as such Boolean product models, and, 
furthermore, if the needed configuration algorithms can be be expressed in terms of basic BDD operations, 
then it is possible to 1) represent the virtual table of general product models using BDDs and 2) use this 
virtual table for performing actual configuration of general products. 

For BDDs it turns out that all these requirements are fulfilled and, furthermore, for most real-life product 
models the algorithms are efficient and the DAGs are compact. In fact, BDDs are the preferred embodiment 
of the DAG. 

However, the invention is not limited to such DAGs. Many other DAGs have representation and algorithms 
that can be viewed as sets and operations on sets, respectively. The DAG must be carefully chosen based on 
the language for expressing the rules in the product model. 

For example, Difference Decision Diagrams (See Nfoller et al: Difference Decision Diagrams. In proceed- 
ings Annual Conference of the European Association for Computer Science Logic (CSL), September 20-25 
1999. Madrid, Spain.) can be used to express (a sub-set of) functions of type K -» 1, and at the same time 
provides the needed algorithms. The immediate advantage is that we thereby have a method of encoding 
product models where the rules comprise (a restricted subset) of quantified expression over variables with 
continuous domains. On the other hand, the disadvantage is that the algorithms are less efficient (satisfiabil- 
ity of the rules that can be encoded turn out to be pspace-hard). 

Another approach, relevant when the rules of the product model comprises more general arithmetic oper- 
ations is the use of BDDs over interpreted Boolean variables (see W. Chan, R. J. Anderson, P. Beame, 
and D. Notkin: Combining constraint solving and symbolic model checking for a class of systems with 
non-linear constraints. In O. Grumberg, editor, Computer Aided Verification, 9th International Conference, 
CAV'97 Proceedings, volume 1254 of Lecture Notes in Computer Science, pages 316-327, Haifa, Israel, 
June 1997. Springer- Verlag.). Each Boolean variable represents a formula, a path in the DAG represents 
a conjunction of such formulas and satisfiability of such path a path can be determined using for example 
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linear programming. 

The encoding the product model as a virtual table will in the following be described in its preferred em- 
bodiment (using BDDs). However, the person skilled in the art can tweak the algorithms to use a different 
underlying data structured, for example one of the two data structures mentioned above. 

Preferred Embodiment for Encoding the Product Model as a Virtual Table 

The preferred embodiment for encoding the product model as a virtual table comprises the following steps: 

Static expansion The product model is expanded by flattening the type hierarchy. The result is a flattened 
product model and a symbol table connecting the product model with the flattened product model. 

BDD encoding A BDD is built for each rule and one big BDD is built representing all consistent configu- 
rations. 

In the following we first show how to perform the static expansion. The flattened product model is the result 
of this static expansion and is created so that it is suitable for encoding using BDDs. 

Static expansion 

The static expansion is performed by flattening the type hierarchy. The result is a flattened product model 
and a symbol table relating the product model and the flattened product model. 

The flattened product model is obtained by 1) the removal of record expressions, 2) simplification of the 
domains and 3) encoding in Boolean form. The removal of record types is done by, for each product variable 
comprising record types, replacing the product variable with a list of flattened variables. Furthermore, all 
expressions over this product variable are replaced by expressions over the flattened variables. After this 
replacement all records have been removed from the product model. For the computer product model, this 
step results in the following product model. (Recall, that motherboard was a product variable of record 
type composed of name, slot and controller): 

types 

cpu-slot-t = [ SLOT-1 | SLOT-A ] , 
controller-t = [ IDE | SCSI ] 

variables 

public motherboard_name : 

[ Abit -BX6 -ATX | Aopen-AX6BP-ATX | Aopen-AK-72-KX133-ATX ] , 
private motherboard_slot : cpu-slot-t, 
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private motherboard_controller : controller- t , 
public harddi sk_name : 

[ IBM-DeskStar-25GP-10, 1GB | Seagate-Barracuda-9-9, 1GB ] , 
private harddisk_controller : controller-t 

public cpu_name: [ Intel-Celeron-A-366MHz | Athlon-AMD-500 ], 
private cpu_slot: cpu-slot-t, 

rules 

motherboard_slot=cpu_slot , 

motherboard_controller=harddisk_controller , 

motherboard_name=Abit-BX6-ATX => 
motherboard_slot=SLOT-l /\ motherboard_controller=IDE, 

motherboard_name=Aopen-AX6BP-ATX => 
motherboard_slot=SLOT-l /\ motherboard_controller=SCSI , 

motherboard=Aopen-AK-72-KX133-ATX => 
motherboard_slot=SLOT-A /\ motherboard_controller=IDE, 

harddisk_name=IBM-DeskStar-25GP-10 ( 1GB => harddisk_controller=IDE, 
harddisk_name=Seagate-Barracuda-9-9, 1GB => harddisk_controller=SCSI, 
cpu_name=Intel-Celeron-A-3 6SMHz => cpu_slot=SLOT- 1 , 
cpu_name=AMD-Athlon-500 => cpu_slot=SLOT-A 

The second step of the flattening of the product model comprises simplification of the domains of the flat- 
tened variables. All flattened values are turned into numbers, and the domain of each flattened variable is 
turned into an interval. For example, for the cpu.slot a value 0 is used instead of SLOT-1 (which was 
the first alternative for the cpu slot) and a value 1 is used instead of SLOT-A (the second alternative). For 
the computer product model, the resulting product model is: 

variables 

public motherboard_name : 0..2, 
public harddi sk_name : 0..1, 
public cpu_name : 0 . . 1 , 

private motherboard_slot : 0..1, 
private cpu_slot: 0..1, 
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private motherboard_controller : 0..1, 
private harddisk_controller : 0..1 



rules 

5 motherboard_slot=cpu_slot, 

motherboard_controller=harddisk_controller, 

motherboard=0 => motherboard_slot=0 /\ motherboard_controller=0 , 
motherboard=l => motherboard_slot=0 /\ motherboard_controller=l , 
motherboard=2 => motherboard_slot=l /\ motherboard_controller=0 , 
10 harddisk=0 => harddisk_controller=0 , 
harddisk=l => harddisk_controller=l , 
cpu=0 => cpu_slot=0, 
cpu=l => cpu_slot=l 

The last step of the flattening of the product model comprises the encoding of the product model in Boolean 
15 form. Each flattened variable is replaced by a list of Boolean variables and each rule is replaced by a new 
rule over these Boolean variables. 

A flattened variable with a domain of type 0 . . n is replaced by flog 2 (n + 1)1 Boolean variables. A unique 
assignment to these Boolean variables is chosen for each of the n + 1 values. For example, to encode the 
three-valued domain (n = 2) of the motherboard_name flattened variable, two Boolean variables are 
20 needed: XO and XI . An assignment of the Boolean variables is chosen for each value in the domain: For the 
value 0: X0=0, X1=0, for the value 1: X0=0, Xl=l, and, finally, for the value 2: X0=1, X1=0. Each rule is 
now replaced by a new rule over the Boolean variables obtaining the flattened product model. For example, 
the flattened product model for the computer product model is: 

variables 
25 public XO, XI, X2, X3 
private X4, X5, X6, X7 



rules 
X4=X5, 
30 X6=X7, 

(XO=0 /\ X1=0) 
(X0=0 A Xl=l) 

(xo=i A xi=o) 

X2=0 => X7=0, 
35 X2 = l => X7 = l, 
X3=0 => X5=0, 



=> X4 = 0 /\ X6=0, 
=> X4=0 /\ X6=l, 
=> X4=l /\ X6=0, 
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X3=l => X5=l 

During the flattening of the product model a symbol table is built. This symbol table comprises two tables. 
The first table contains information about type, the domain of each of the flattened variables as well as the 
Boolean variables used to encode values for this variable. For the computer product model, this table is: 



Flattened variable 


Type 


Integer domain 


Boolean variables 


motherboarcLname 


public 


0..2 


XO, XI 


harddisk_name 


public 


0..1 


X2 


cpumame 


public 


0..1 


X3 


motherboarcLslot 


private 


0..1 


X4 


cpu-slot 


private 


0..1 


X5 


motherboard-controller 


private 


0..1 


X6 


harddisk-controller 


private 


0..1 


X7 



The second table relates the flattened values, their integer values and the unique Boolean assignments. For 
the computer product model, this table is: 



Flattened variable 


Flattened value 


Integer value 


Boolean values 


motherboard-name 


Abit-BX6-ATX 


0 


0,0 


motherboard-name 


Aopen-AX6BP-ATX 


1 


0,1 


motherboard-name 


Aopen-AK-72-KXl 33-ATX 


2 


1,0 


harddisk_name 


IBM-DeskStar-25GP- 1 0, 1 GB 


0 


0 


harddisk_name 


Seagate-Barracuda-9-9, 1 GB 


1 


1 


cpu_name 


Intel-Celeron-A-366MHz 


0 


0 


cpumame 


Athlon-AMD-500 


1 


1 


motherboarcLslot 


SLOT-1 


0 


0 


motherboard_slot 


SLOT-A 


1 


1 


cpu_slot 


SLOT-1 


0 


0 


cpu_slot 


SLOT-A 


1 


1 


motherboard-controller 


IDE 


0 


0 


motherboard-controller 


SCSI 


1 


1 


harddisk_controller 


IDE 


0 


0 


harddisk-controller 


SCSI 


1 


1 



BDD Encoding 

10 The construction of the DAG is now performed. The preferred embodiment is a (Reduced Ordered) Binary 
Decision Diagram. 
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The use of Boolean Decision Diagrams for the representation of Boolean formulas is well known. For 
an introduction to Boolean Decision Diagrams see [Cristoph Meinel & Thorsten Theobald: Algorithms 
and Data Structures in VLSI Design, Springer 1998]. We will use the following (well known) textual 
representation of BDDs: 

• 0 represents the terminal BDD 0 (true), 

• 1 represents the terminal BDD 1 (false), 

• {a® b) represents the BDD obtained by applying a and b with the any binary Boolean operator denoted 
by ® operator. 

• 3x.a represents the BDD obtained by existentially quantifying out the variable x from the BDD a. 

• (x -> a, b) is the BDD representing the formula if x then a else b, which can be expressed in terms of 
simpler operators as (a; A a) V (-<x A b). 

BDDs has a well known graphical representation. Figure 5 is an example of this representation. The figure 
is a BDD over two variables Xq and X\. The chosen ordering < of the variables is X 0 < X\ and the BDD 
represents the formula: 

X 0 -> -> 0, 1), 1) = (-X 0 ) V (-.Xi). 

Basic operations on BDDs for the construction and decomposition of BDDs are sketched in Algorithm 1. 
The algorithm Mk is used for the construction of vertices, the algorithm Apply for applying an operator on 
two vertices and the algorithm Exists for building a BDD representing the existential quantification of a 
variable in a BDD. The algorithms Var, Low and High are simple functions used for decomposing BDDs: 
Var(u) returns the variable associated with the vertex u, Low(u) returns the low-son associated with the 
vertex u and High(u) returns the high-son associated with the vertex u. The algorithm FullOneSat(w) 
computes a new BDD v fulfilling v -> u such that the BDD u has exactly one satisfying assignment 
(naturally, u must be feasible, i.e., contain at least one solution). The algorithm AnySat(u) returns a 
satisfying assignment of values to the variables in u (again, u must be feasible). Finally, the algorithm 
SatCount(u) returns the number of assignments satisfying u. 

The construction of the BDD representation takes its basis in the flattened product model. First, a suitable 
ordering of the Boolean variables are chosen. The choice of this ordering is important for the size of the 
constructed BDDs. In the preferred embodiment, the ordering is chosen by keeping Boolean variables 
representing the same flattened variable next to each other. A suitable ordering for the computer product 
model is X 0 <X, < X 2 < X 3 < X A < X h < X % < X r . 

Having chosen an ordering, each of the rules is encoded as a BDD. For example, the BDD for the third 
rule (X0=0 A X1 = 0) => (X4 = 0 A X6=0) is constructed by encoding the expression (shown in 
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Figure 4): 

(^X 0 A ->Xi ) — > (-.JT 4 A -.X 6 ). 

The encoding is performed using the well known Mk and Apply algorithms. In the following the set R 
refers to the set of rules, each rule encoded as a BDD. 

Thereafter, a domain constraint representing the possible Boolean variable assignments is made for each 
flattened variable. For example, three possible values exists (0, 1 and 2) for the flattened variable 
motherboard_name. Therefore two Boolean variables are used to encode the domain using the assign- 
ments (X0=0, X1=0), (X0=0, Xl=l), and, (X0=1, X1=0), respectively. In Figure 5 the BDD for the domain 
constraint for motherboard_name is shown. Observe that the remaining (unused) assignment (X0=1, 
Xl=l) leads to the terminal 0. Since the domain size of all the other flattened variables is 2 (correspond- 
ing to a single Boolean variable), it turns out that all other domain constraint BDDs are represented by the 
terminal BDD 1. The preferred method for building these BDDs is also by the use of the Mk and APPLY al- 
gorithms. In the following the set D refers to the set of domain constraints, each domain constraint encoded 
as a BDD. 

The BDDs built at this stage will be used as building blocks for the creation of one big BDD representing 
all rules R and all domain constraints D. This BDD is built by first conjoining the BDDs for the individual 
rules to one BDD R^: 

= A 

refl 

Here Arefl r denotes the result of conjoining together all elements r from R. 

Figure 6 shows this BDD for the computer product. Notice that in this BDD it is in fact possible to select 
X0=1 and Xl=l and still reach the 1 terminal. This is caused by the fact that the domain constraints are not 
taken into account. A BDD containing all domain constraints D a n is therefore built: 

A* = Ad. 

deD 

A BDD representing all possible consistent configurations is obtained by conjoining all the BDDs for all 
rules and all domain constraints. 

C a n = f i? a ll A r> a u. 

For the computer product model this BDD is shown in Figure 7. Observe that exactiy three different paths 
containing all the variables lead to the terminal 1 . Thus, for the computer product model exactly three 
consistent product configurations exists (one based on each of the different motherboards). 

The preferred method of building i? a n, D a n and Caii is by use of the algorithm Multi Apply shown in 
Algorithm 2. Given an associative and commutative operator <g> and a set of vertices U = {u\, ... , «„} the 
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algorithm returns a BDD representing: 

«i ® • ■ • <8> u n . 

As mentioned earlier only the public flattened variables are supposed to be available to the end user during 
configuration. It is possible to build a smaller BDD over only these variables without throwing necessary 
information away. This BDD is built by existentially quantifying out the set of private flattened variables 
(referred to as the set F pr iv) preferably using the MultiExists algorithm shown in Algorithm 3 (Let V^ v 
refer to the set of Boolean variables representing V pr iv): 

Cpub = ^V^iv Call, 

where we use 3W on a finite set of variables W = {xi,...,x m } as a shorthand for m quantifiers: 
3^i- • • • .3a; m . 

For the computer product model the results is the BDD shown in Figure 8. In the figure any path leading 
from the top vertex to the terminal 1 represents one or more assignments of Boolean variables that makes up 
a consistent configuration of the computer. More assignments are represented if some variables are absent 
on a path: these can take on any of the values 0 or 1 and still result in a consistent assignment. Using the 
symbol table it is possible to relate this information to the original flattened variables. 

Early Quantification 

For big product models it turns out that first building the BDD for the entire set of consistent configurations 
and thereafter quantifying out the private variables yields very big BDDs during the construction. A further 
advantage can be obtained by adapting a technique known as early quantification to the encoding process 
(see [J. R. Burch, E. M. Clarke, D. E. Long: Symbolic Model Checking with Partitioned Transition Relations. 
Proceedings of the 1991 International Conference on VLSI]). The key observation is that if a variable is not 
free in a rule you can "move" the existential quantifier down below the conjunction in the conjunctive 
combination of the rules: 

3a;. (a A b) = a A (3x.b) if a; is not free in a. (1) 

The preferred embodiment of the adaptation of this technique is as follows: A graph (V, E) is constructed 
comprising vertices V, each labelled with one flattened variable, and edges E, each labelled with one rule. 
The graph is undirected, but more than one edge can connect two vertices (a multi-graph). The graph 
contains: 

• A vertex labelled v for each private flattened variable v. (This vertex will be referred to as the vertex 
v.) 

• For each pair of vertices v, w and rule r an edge between v and w if the flattened variables v and w 
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are both free in r. (This edge will be referred to as the edge (v, r, w).) 

Based on the constructed graph a strongly connected component graph is created (see for example: [Cor- 
men, Leiserson, Rivest: Introduction to Algorithms, p. 488-490]). Let S denote the set of strongly connected 
components. Each of the strongly connected components comprises a sub-graph. Let Gj = (Vi,Ei) com- 
prise the i'th of these sub-graphs (for 1 < % < \S\). Vt is the private flattened variables in this sub-graph and 
= { r | {v,r,w) £ Ei} is the rules in this sub-graph. 

Now, a private flattened variable in a graph Gj is by construction not free in all rules not in Using the 
observation shown in Equation 1 this means (let Vf be the Boolean variables representing Vj): 

ie{i \s\} reik 

An ordering of rules and flattened variables are now made by performing the following steps: 

• For each sub-graph d choose an ordering of the flattened variables Vj inherent in the sub-graph. Let 
Oi denote the ordered list of these flattened variables. 

• Define an ordered list of all the flattened variables O = (0{~ . . .~ O n ) = . . . ,v\ v \)- 

• Sorting the rules based on the ordering 0. 

The last step is preferably performed by the algorithm OrderRules shown in Algorithm 4. This algorithm 
takes as input 1) the list of ordered flattened variables O and 2) the edges E. The call OrderRules (O, E) 
returns a list of sets of rules F = {F u . . . ,.Fj V |) where invariantly: 

V*,i S {1, . . . , \V\} : (i < j (ih n freevars{Fj) = 0)). (2) 

Now, combining Equation 1 and Equation 2 we can determine the set of consistent configurations C pub by 
1) starting with a BDD for the domain constraints £> a u, 2) repeatedly, for increasing i (1 < i < \V\), on 
this BDD first conjoining the rules in and thereafter quantifying out the Boolean variables representing 
Vi. This task is performed by the algorithm ConjoinExists which is preferably implemented as shown in 
Algorithm 5. The set of consistent configurations is (where O b is the list of vectors of Boolean variables 
for the encoding of O, {vf, ... , v^^}): 

C pub = ConjoinExists (0 s , F,D aU ). 

In most BDD packages the number of declared variables are given at initialisation time, say n. Variables are 
then referred to using an index between 0 and n - 1. The number of declared variables are used for example 
in the SatCount algorithm. Even though the free variables of C pub only are among the public Boolean 
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variables, we cannot just use SatCount to count the number of consistent configurations. It would give 
us a number that is a factor V to big, where j is the number of private Boolean variables. To get the 
correct number of consistent states we must either divide the result with this factor or, alternatively, we can 
re-initialise the BDD package with a declared number of variables equal to the number of public Boolean 
variables (we then need to re-encode the BDDs wrt. to the new variable indexes). We shall choose the latter 
approach. 



Encoding Arithmetic Expressions 

The computer product model does not contain any arithmetic operations. However, as described earlier, the 
preferred embodiment of the product model does allow certain carefully selected arithmetic expressions: ad- 
dition of two expressions, subtraction of two operations, and multiplication of an expression with a constant. 
These arithmetic operations are allowed because 1) they turn out to be useful during product modelling and 
2) at the same time efficient BDD operations for encoding such expressions exist. 

The key observation is that during static expansion and just before the product model is encoded in Boolean 
form, all expression in all rules are Boolean combinations of these basic arithmetic operations as well as 
(inequalities over the flattened variables. Using standard Boolean equivalences all rules can be written on 
a form generated by the following grammar (written on BNF form): 

bexpr ::= bexpr h bexpr (Conjunction) 

| -i bexpr (Negation) 

| aexpr bop aexpr (Arithmetic operator) 

bop ::= < | < | = | > | > | 7^ (Boolean operators) 

aexpr ::= aexpr aop aexpr (Arithmetic operator) 

| constant \ variable (Atomic arithmetic expression) 

ao p :: = + | - | *, (Arithmetic operators) 

where constant represents a constant and variable represents a flattened variable. 

It is well known how to encode these arithmetic operations in BDDs. Two reference are [Alan John Hu: 
Techniques for Efficient Formal Verification Using Binary Decision Diagrams. Ph.D. thesis, Stanford Uni- 
versity, Department of Computer Science, Technical Report Number CS-TR-95-156] and [Jorn Bo Lind- 
Nielsen: Verification of Large State/Event Systems. Ph.D. Thesis., Department of Information Technology, 
Technical University of Copenhagen, IT-TR: 2000-032.] 



Encoding Product Tables 

As mentioned earlier a product table (typically represented in a database) can be used to represent a rule 
in an adequate manner. It is not necessary to first explicitly translate the product table to a textual rule and 
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thereafter translate the rule into a BDD. Instead a BDD can be built directly from the product table. 
The preferred embodiment for this process is the algorithm VirtualizeTable shown in Algorithm 6. The 
algorithm tabulates each cell, builds a BDD for this cell and accumulates the results of the tabulation in 
temporary BDD nodes. The auxiliary function VirtualizeCell builds a BDD for a specific cell. The 
implementation of this algorithm will use the symbol table for finding out how to map flattened variables to 
Boolean variables. 

Table filters are easily added to this method by adding information relating to the table filters to the symbol 
table and changing the auxiliary function VirtualizeCell to use this information. 



Encoding Sum Types 

The computer product model contains values of enumerated type (for example [ IDE | SCSI ] ). A 
more general type that can also be encoded using BDDs is the sum type (known from many classic type 
systems). This compound type allows a tag (as in the enumeration case) and a value (which can have any 
type). An example of a sum type modelling that an extra harddisk can either be absent or present (with a 
specific type) is: 

variables : 

extraharddisk : [ ABSENT | PRESENT of [IDE | SCSI]] 

Possible values for extraharddisk are ABSENT, PRESENT ( IDE) and PRESENT (SCSI ). If we want 
to encode one of these values we must 1) capture whether we have selected the ABSENT or PRESENT tag 
and 2) in the latter case which sub-value (IDE or SCSI) we have selected. The preferred embodiment is 
to encode these two parts separately. In this specific case: One Boolean value (P) indicating that the extra 
harddisk is PRESENT and one Boolean variable (T) indicating that the type is SCSI. 
Observe that using this encoding the value of T does not make sense if P=false. (Two different value 
assignments exist where P = false: P = false, T = false and P = false, T = true.) To limit the size of 
the representation and to be able to count the number of meaningful assignments we choose a default value 
for each sub-value. Then we define a normalisation constraint expressing that whenever this sub-value is 
not selected the sub-value must have the default value. For the extraharddisk example we choose the 
default value for T to false. Hence, the normalisation constraint is: 

(P = false) —¥ (T = false). 

Should such sum types occur all normalisation constraints must be conj oined on the BDD C pu b for obtaining 
the final BDD representing the set of consistent configurations. 
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Interactive Configuration using the Virtual Table 

The virtual table is now used for performing a configuration. Without limiting the invention a user is 
normally involved in this process. The user interacts with a computer program, a configuration assistant, 
interfacing to the virtual table. Generally, the configuration session performed by the user and the computer 
program can be viewed as an interactive iterative configuration where the configuration assistant guides the 
user through the configuration process: 

• the configuration assistant uses the virtual table to find information that is provided to the user, and 

• the user provides information relating to his/her wishes. 

The "protocol" for such a configuration session can be constructed in many ways. Without limiting the 
invention the session will typically be an iterative process comprising the following steps (seen from the 
perspective of the configuration assistant): 

1 . Inspecting the virtual table. The amount of information inherent in the virtual table is generally 
enormous. Therefore, the configuration assistant must be able to extract only limited amounts of 
information from the virtual table. Still, the provided information must be sufficient and relevant in 
the given context (where the context typically is earlier made selections.) 

2. Providing the user with this information. This must be provided in a way so that the user is able to 
tell which options he/she has at the given time, and how selections will influence on the consistency 
of the configured product. 

3. Allowing the user to make/undo selection(s). The configuration assistant has, at this stage, provided 
the user with information so that it is easy for the user to perform consistent selections, but it might be 
the case that the user anyway makes a selection incompatible with earlier selections. The configuration 
assistant must deal with all such cases in a reasonable manner. What is reasonable depends on the 
application. However, often the configuration assistant will have to sacrifice some earlier selections 
to, again, reach a consistent set of selections (informing the user of these sacrifices). 

4. Using the virtual table for computing the consequences of the selections made by the user. 

The iterative process goes on until the user decides to terminate the session. If a consistent and complete 
configuration has been found at this stage, it can be provided to an order placement system, etc. 

The communication between user and configuration assistant is performed through a user interface. Figure 3 
is a screenshot of a user interface for a pc product model. The user interface allows the user to see already 
performed selections (for example, the user has selected the alternative IBM Deskstar 25GP 10,1GB 
for the component Harddi sk 1), see what alternatives that are available (here, by a "pop-up" window, 
currently showing CPU alternatives), and which of these alternatives that are compatible with all earlier 
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selections (here, by using a black background colour). The user can select an alternative for a component, 
de-select earlier made configurations, etc. Two additional features make the life easier for the user: 

• A button (Conf iglt ! ) is provided for letting the configuration assistant finish off the configuration 
(by performing consistent selections of all unselected components) when the user has performed all 
selections he/she wishes. 

• Other buttons allow the user to choose preconfigured selections, for example the pc shop's standard 
workstation. The user is afterwards still free to modify the workstation, and will still receive help 
from the configuration assistant. 

A common case is to present such a user interface in a web browser, obviously allowing the use of the 
Internet for communication. The virtual table can either be placed on a virtual table server or on the client 
running the web browser. In the first case, the configuration assistant will comprise a server and a client 
thread (running in parallel, communicating through the Internet). In the second case, the configuration 
assistant will typically run solely inside the web browser. Both approaches are feasible and the method of 
deployment must be based on which properties are required for the given configuration session. However, 
the first approach is the preferred embodiment. 

Recall that in our framework the components correspond to flattened product variables, and the alternatives 
correspond to values. Without limiting the invention the following pseudo code describes how the config- 
uration assistant generally runs (obviously, the details can be handled in many ways: the exact commands 
available to the user can be different, the feedback from the system can differ, the order of many of the 
involved steps can be changed): 

S<-<> 
repeat 

Show Status (5) 

C <- ReadFromUser(S) 

if C — exit then 

return S 

end 

S <- UpdateSelection(S, C) 
end 

The variable 5 is an ordered list of selections, each selection comprising a pair (v, d) where v is a flattened 
variable and d is a flattened value. The selections generally represent a non-empty set of the consistent 
configurations available in the virtual table. 

Initially no selections have been made, hence S is the empty list, representing the complete set of consistent 
configurations in the virtual table. 

Information that can be obtained from S and the virtual table is now presented to the user. Typically, for 
each flattened variable the user is shown the possible selections that are compatible with S. 
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Now, the user is queried for a command C. The command can be the selection of one of the selections 
that were compatible with S, the de-selection of a selection already in S, the forcing of a selection, or, if a 
selection is made for all public flattened variables, exiting the configuration. 

Based on the command C and the previous selections S a new selection list is computed as follows: 

• In the select case the new selection is compatible with S. The new selection is therefore simply added 
to the end of S. S will now represent a smaller (or equivalent) set of configurations. 

• In the de-selection of an earlier selection, the selection is simply removed from the list S. S will now 
represent a larger (or equivalent) set of configurations. 

• The force case of a selection is a bit more complex. Forcing means: "Even though this selection is 
not compatible with other selection force this selection, sacrificing other selections in 5." A new S' is 
found by: 

1 . Adding the new selection to the front of S. (Recall, S is an ordered list.) 

2. Initialising 5' to a new empty list (). 

3. Starting from the front of 5, for each selection s in S: 

- If s is compatible with selections in S' add s to the end of S'. 

- If s is incompatible with selections in S' throw s away. 

4. The new selections are S'. 

• In the exit case we are finished and the consistent and complete configuration S is returned and for 
example passed on to an order placement system. 

Even though details regarding the communication between the user and the configuration assistant are 
changed, it turns out that the basic algorithms on the virtual table for the implementation of the pseudo 
code are more or less the same. The following key algorithms are generally needed: 

• Algorithm(s) for combining a virtual table with one or more selections and for checking whether the 
combination is consistent. 

• An algorithm, that for a virtual table and a prioritised list of possibly inconsistent configurations, can 
determine which of the selections can be allowed and which of the selections will be "sacrificed" for 
making the selections consistent. 

• An algorithm that for a virtual table and some consistent selections determines consistent selections 
for all unselected components. 

• An algorithm for counting the number of consistent configurations for a given set of selections. 
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• An algorithm that, for a variable, determines possible selections that are compatible with earlier se- 
lections. 

These algorithms are generally implemented utilising the basic algorithms of the DAG in the virtual table 
(for the BDD case, the algorithms shown in Algorithm 1). 

Preferred Embodiment for the Interactive Configuration 

The preferred embodiment for the interactive configuration system is a configuration assistant comprising 
a server and a client thread running on a virtual table server and in a web browser, respectively. First, the 
preferred embodiments of key algorithms on the virtual table is provided. Thereafter, the server and client 
algorithms are presented. 

The basic BDD algorithms utilises a programming technique known as dynamic programming. As a conse- 
quence results of computations on the BDDs are being cashed (depending on available memory, etc). This 
implies that a re-computation with the same arguments generally will run in constant time. A couple of the 
algorithms utilises this: Instead of maintaining tables with temporary BDDs the underlying operations are 
called (with the same arguments) and the result are (generally) available in constant time. This approach 
further more allows for the implementation of a "state-less" server. 

The first four key algorithms concern the combinations of the virtual table and selections. 

The first algorithm CONFlGl shown in Algorithm 7 is used for combining the virtual table (Cactual) with one 
selection. The selection comprises a flattened variable v and a value d. First a BDD u is built, representing 
the selection. This BDD is build by 1) determining the Boolean variables {vi, . . . ,v n ) representing v and 
the Boolean values {d\. . . . , d„) representing d (by querying the symbol table), 2) for each pair of 
Boolean variables and values building a BDD for (vi = ck), and 3) combining these BDDs using Multi- 
Apply(-k •) obtaining one BDD. Thereafter, u is conjoined with the BDD representing the virtual table 
yielding a new BDD. This BDD is the set of consistent configurations respecting the original virtual table 
(representing, for example the rules of the product model) as well as the selection {v = d). Note, that the 
empty set of configurations is represented by the BDD 0. Thus, if the resulting BDD is 0, the virtual table is 
incompatible with the selection. 

Recall the example computer product model discussed in the previous sections. In Figure 8 the BDD rep- 
resenting the rules and the domain constraints was shown. The BDD representing the set of consistent 
configurations under the selection of the harddisk to Seagate-Barracuda-9-9, 1GB can be deter- 
mined by CONFlGl. The result is shown in Figure 9. Note, that only one path leads to 1. This means 
that all other components are chosen implicitly by the selection of the harddisk. By inspecting the sym- 
bol table on page 29 it is easy to see that this correspond to the Aopen-AX6BP-ATX motherboard, the 
Seagate-Barracuda-9-9, 1GB harddisk (of course), and the 
Intel -Celeron-A-366MHz cpu. 
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The algorithm ConfigConsistent shown in Algorithm 8 builds a BDD representing several selections 
5 new . The algorithm simply applies ConfigI iteratively, yielding a BDD representing smaller and smaller 
sets of configurations. Note, that should the selections be incompatible the BDD returned is 0 and it is 
impossible to see "when" the problem occurred. 

The algorithm ConfigCheck shown in Algorithm 9 takes care of this. The ordering of the selections in 
5 new is used for prioritising selections. As in the previous algorithm ConfigI is applied to the individual 
selections. As long as the selections are consistent the selections are added to a list of consistent selections. 
However, should a selection turn out to be inconsistent with the earlier selections the selections is "rejected" 
and the previous set of configurations are kept. The rejected selections are put together in a list. When 
the algorithm are finished it returns a BDD representing a non-empty set of configurations. Under the (rea- 
sonable) assumption that the initial virtual table is non-empty this algorithm will invariantly return a BDD 
representing a non-empty set of configurations. The list of consistent and rejected selections is furthermore 
returned. 

The next algorithm ConfigIt shown in Algorithm 10 is used for 1) restricting the set of configurations 
based on a set of compatible selections and 2) automatically selecting compatible values for the remaining 
product variables. The algorithm starts of as ConfigConsistent yielding a BDD representing a non- 
empty set of solutions Cactuai- Thereafter, the known BDD algorithm FullOneSat is used. This algorithm 
builds a BDD comprising a single path in from Cactuai- This BDD will represent exactly one configuration. 
The known BDD algorithm AnySat is then used to obtain the Boolean selections represented by this path. 
By "backwards" use of the symbol table the product selections is determined. 

The next two algorithms are used for querying a virtual table. 

The algorithm ConfigCount shown in Algorithm 1 1 counts the number of consistent configurations in a 
virtual table. The algorithm SatCount is used to determine this number. However, three important details 
for being able to just return this number are: 

1 . In the preferred embodiment of the encoding of the virtual table domain constraints was conjoined on 
the virtual table. Without domain constraint, "illegal" paths would exists, yielding a wrong number 
of configurations. 

2. In the preferred embodiment of the encoding of the virtual table all sum types were normalised. 
Without normalisations there would be more than one Boolean selections of variables for the value 
ABSENT (from the example on page 35) yielding a wrong number of configurations. 

3. In the preferred embodiment of the encoding of the virtual table the BDD package was re-initialised 
after building the virtual table, thereby removing the private Boolean variables. In the case where the 
BDD package is not re-initialised it is necessary to divide the number obtained from SatCount with 
2", where n is the number of private Boolean variables (obtained by inspecting the symbol table). 
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Using ConfigCount on the BDD representing the virtual table of the computer product model returns the 
number of consistent configurations of the computer, three. This number can also be found by counting the 
number of paths leading to 1. 

The algorithm DetermineDomain shown in Algorithm 12 determines, for a given flattened variable Vi 
and a virtual table C actua i, which possible values can be selected. The algorithm works by existentially 
quantifying out all the Boolean variables X except for the Boolean variables vf representing «j. The result 
of these existential quantifications is a BDD that — viewed from a configuration perspective — represents 
a virtual table. This virtual table has the nice property that it only contains one column (the column with the 
possible values for Vi). Since a product variable by virtue of the shape of the virtual table cannot have any 
interdependencies with other variables (only one column) the domain can be determined simply by listing 
the elements in the virtual table. This is done by: 1) Finding the set of assignments of the Boolean variables 
v\ in the virtual table. 2) translating each of these to flattened values. 

An illustrating example is to determine the domain of the motherboard-name flattened variable for the 
initial virtual table of the computer productmodel. The Boolean variables representing motherboard_name 
is XO and XI. All other Boolean variables are existentially quantified out yielding the BDD shown in Fig- 
ure 10 (structural equivalent to Figure 5). This BDD has three assignments of Boolean variables XO and XI : 
(0,0), (0,1) and (1,0). By using the symbol table we can determine the corresponding flattened values. 

The algorithms described above can be used to implement many different configuration systems. We will 
now show how they are used in a configuration assistant comprising a server and a client thread communi- 
cation over a network such as the Internet. The virtual table is located on a virtual table server that performs 
the needed computations during configuration. A client is used for presenting a user with information re- 
garding the configuration process and for querying about selections, etc. 

The preferred implementation comprises the two threads ConfigClient (on the client side) and the al- 
gorithm ConfigServer (on the server side). The two algorithms are shown in Algorithm 13 and Algo- 
rithm 14, respectively. 

The ConfigClient runs during one configuration session. When the user has found a suitable configura- 
tion and wishes to stop the configuration session the algorithm returns with the obtained configuration. (The 
"return" is in real life typically replaced by sending the result to an order placement module, etc.) 

The ConfigServer algorithm is non-terminating. Upon start it enters a loop awaiting a client to serve. 
When it receives a configuration command from a client it computes a result and immediately returns this 
result to the client. Thereafter it loops back to start, awaits for a new command from a new client (or possibly 
the same), and so on. 

Communication is specified using standard primitives such as Send and RECEIVE. The protocol is that: 
Initially the client sends a configuration command to the server. The server receives this configuration 
command and computes the result. This result is passed back to the client. The client receives the result, 
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provides information to the user and queries the user for a user command (a selection, exiting, etc.). Upon 

receiving this user command a new configuration command is send to the server, and so on. 

The client is provided a single argument: the set of public flattened variables. The algorithm runs as follows. 

1. First a configuration command is sent to the server, saying "provide me with information relating to 
the empty list of selections". 

2. Thereafter information is received from the server comprising: 

^actual A list of selections already made by the user. 

Rejected A l ist of selections rejected due to incompatibilities obtained through a 

Force operation (details follow). 

N The number of consistent configurations respecting the selections al- 

ready made. 

(£>!,..., ,D re } For each public flattened variable u 4 the set of values that can be selected 
without reaching an inconsistent configuration. 

3. This information is presented to the user. 

4. A command from the user is received I. The possible user commands are: 

• Selected). Add the selection of the public flattened variable v with value d (that is, the 
pair (u,d). The user interface must ensure that if v is the variable Vi, then d G A (hence, the 
selection leads to a consistent configuration). 

• Force(i), d). Add the selection of the public flattened variable v with value d. If the selection 
is inconsistent with an earlier selections s 1 the user wishes that s' is rejected. 

• Deselect (v). Remove the selection of the public flattened variable v. 

• Reset. Remove all selections. 

• PreConf igure (S). Remove all selections and instead pick a standard list of selections 5 (for 
example, a standard workstation.) 

• Conf iglt. For all public flattened variables where a value has not been selected let the con- 
figuration program pick any consistent selection. 

• Stop. Exit the interactive configuration. Let the server return the actual selections to the calling 
program, for example a order placement system. The user interface must ensure that the current 
selections comprises a complete selection (that is N must be 1). 

5. Now, if the user command is Stop the algorithm terminates and returns the obtained selections. 

6. Otherwise, a configuration command is constructed and sent to the server. Possible configurations 
command are: 
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• Conf ig (5) . Command the server to compute information relating to the (possibly inconsistent) 
selections S. The selections S are constructed as follows: 

- For a Select user command the new selection is simply added to the end of the selection 
list. 

- For a Force user command the new selection is instead added to the front of the selec- 
tion list: Should an inconsistency exists the force'd selection will be accepted and other 
selections (placed later in the list of selections) will be rejected. 

- For a Deselect user command the relevant flattened variable is simply removed from the 
selection list. 

- For Reset the new selection is empty. 

- For PreConf igure the new selection is a based on the standard list. 

• Conf iglt. Compute information relating to the consistent selections 5. For all public flattened 
variables where a value has not been selected, pick any consistent selection. 

7. Thereafter information is again received from the server and so on, see step 2. 

The purpose of the server algorithm is to provide the computational needs for the client algorithm and can 
be viewed as glue code between the client and the key configuration algorithms described earlier. The server 
algorithm is provided the following arguments: 

Cbasic The BDD Cpub representing the virtual table. 

(vi , . . . , v n ) Th list of public flattened variables. 

Y The symbol table 

During computation the variable 5 actU ai is an (ordered) list of selections the user has made. Each of these 
selections comprises a pair (v, d) where v is a public flattened variable and d is a value from the domain of 
v. The BDD C a ct U ai represents all consistent configurations with respect to the actual selections Sactuai- 

The algorithms runs as follows: 

• The server receives a configuration command and an ordered list of selections S new . 

• If the command is Conf ig, 5 new might be inconsistent. Therefore, the algorithm ConfigCheck is 
used to build a set of consistent configurations and building the lists of accepted and rejected selec- 
tions. 

• Alternatively, if the command is Conf iglt, 5 ne w is consistent, but remaining selections must be 
made. This is done using the ConfigIt command. 

• Thereafter, the actual number of consistent configurations is determined. 

• And, for each variable, the actual possible values are determined. 
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• The computed information is sent back to the server, and the algorithm loops awaiting a new com- 
mand. 

Finally, we will describe the preferred method of deployment of the configuration assistant on the Internet 
is as follows: 

• A user wishing to perform a configuration first connects to a web server. 

• The web server returns the implementation of ConfigClient to be executed in the user's browser 
(preferably implemented in Java Script). 

• When ConfigClient is initiated in the client web browser it connects to a virtual table server (not 
necessarily the web server) holding the virtual table and running the ConfigServer algorithm. 

• The client and server threads communicates as described earlier. 
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Annex A: XML Document Type Declaration for the Product Description 



<!-- DTD for Configlt projects - Copyright (C) 2000 Configlt --> 
<! ELEMENT project (head, entities) > 
< ! ELEMENT head (name, description) > 

<! ELEMENT entities ((constant | dbconstant) * , type*, productvariable*, 

(rule | dbrule)*, database?) > 
< ! ELEMENT constant (name, description, expression) > 

<! ELEMENT dbconstant (name, description, sqlalias, filteralias, expression) > 
< ! ELEMENT type (name, description, typeconstructor) > 

< ! ELEMENT typeconstructor ( (boolean | subrange | array | product | 

sumtype | sumdb | idtype | label) , 
optional?) > 

< ! ELEMENT boolean EMPTY> 

<! ELEMENT subrange (expression) > 

< ! ELEMENT array (expression, typeconstructor) > 

<! ELEMENT product (prodvar*, (rule | dbrule) *)> 

< ! ELEMENT prodvar ((private | public), name, description, 
typeconstructor) > 
< [ELEMENT private EMPTY> 
<! ELEMENT public EMPTY> 
<! ELEMENT sumtype (sumvar*)> 

< ! ELEMENT sumvar (name, description, typeconstructor) > 
<! ELEMENT sumdb (sqlalias, filteralias) > 
< ! ELEMENT idtype (# PCDATA) > 
<! ELEMENT label EMPTY > 
< ! ELEMENT optional EMPTY > 
< ! ELEMENT productvariable (name, description, (private | public), 

typeconstructor) > 
< ! ELEMENT rule (name, description, expression) > 
< ! ELEMENT database (alias | sqlquery j filter) *> 

<!ELEMENT alias (name, description, dsn, username, password) > 
<! ELEMENT dsn (#PCDATA) > 
< ! ELEMENT username (#PCDATA) > 
<! ELEMENT password (#PCDATA) > 
< ! ELEMENT sqlquery (name, description, query, dbalias)> 
<! ELEMENT query (# PCDATA) > 
< ! ELEMENT dbalias (# PCDATA) > 
< ! ELEMENT dbrule (name, description, sqlalias, mapping*) > 
< ! ELEMENT sqlalias (# PCDATA) > 

<!ELEMENT mapping (variable, lambdaexpr, lambdavar, column, filteralias) 
< ! ELEMENT variable (expression) > 
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<! ELEMENT lambdaexpr (expression) > 
<! ELEMENT lambdavar (#PCDATA) > 
<! ELEMENT column (#PCDATA) > 
< ! ELEMENT filteralias (#PCDATA) > 
5 < ! ELEMENT filter (name, description, f ilterfunction, settings) > 

< ! ELEMENT f ilterfunction (#PCDATA)> 

< ! ELEMENT settings (number | true | false | string | numbers | 
booleans | strings) *> 
< ! ELEMENT string (#PCDATA) > 
10 < ! ELEMENT numbers (number) *> 

< ! ELEMENT booleans (true | false) *> 
<! ELEMENT strings (string) *> 
<! ELEMENT name (#PCDATA) > 
<! ELEMENT description (# PCDATA) > 
15 < ! ELEMENT expression (idconstructor | number | true | false | and | or | 
xor | imp | biimp | plus | minus [ mult ( It | lteq | gr | greg | eq | 
neq | shftl | shftr | not | forall | exist | sum | prod [ case | sumvalue 
if>> 

< ! ELEMENT idconstructor ((idname, indexlist?) | (idconstructor, 
20 idconstructor) ) > 

<! ELEMENT idname (#PCDATA) > 
< ! ELEMENT indexlist (expression+) > 

<! ELEMENT number (#PCDATA) > 

<! ELEMENT true EMPTY > 
2S <! ELEMENT false EMPTY > 

<! ELEMENT and (expression, expression) > 

<! ELEMENT or (expression, expression) > 

<! ELEMENT xor (expression, expression) > 

< ! ELEMENT imp (expression, expression) > 
30 < ! ELEMENT biimp (expression, expression) > 

<!ELEMENT plus (expression, expression) > 

<!ELEMENT minus (expression, expression) > 

<! ELEMENT mult (expression, expression) > 

< I ELEMENT It (expression, expression) > 
35 <! ELEMENT lteq (expression, expression) > 

< ! ELEMENT gr (expression, expression) > 

< ! ELEMENT greq (expression, expression) > 

<!ELEMENT eq (expression, expression) > 

< ! ELEMENT neq (expression, expression) > 
40 < ! ELEMENT shftl (expression | (expression, expression) ) > 

< ! ELEMENT shftr (expression | (expression, expression) ) > 

< ! ELEMENT not (expression) > 
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<! ELEMENT forall (idname, range, expression) > 

< ! ELEMENT range (expression, expression) > 
< ! ELEMENT exist (idname, range, expression) > 
< ! ELEMENT sum (idname, range, expression) > 
< ! ELEMENT prod (idname, range, expression) > 
< 'ELEMENT sumvalue (name, expression) > 
< ! ELEMENT if (test, then, else) > 

<! ELEMENT test (expression) > 

<! ELEMENT then (expression) > 

<! ELEMENT else (expression) > 
< ! ELEMENT case (idconstructor, pattern+, expression) > 

<! ELEMENT pattern (expression, expression) > 
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Annex B: Algorithms 



Alg orithm 1 

function Mk(i, ft, I) : Var x V x V -4 V 
return (A vertex representing (x -> ft, I).) 

function Var (it) : V -» Var 
return (If u represents (v -4 ft, I), return v.) 

function Low(u) : V -» V 
return (If u represents (v -> ft, Z), return Z.) 

function High(u) : F -> V 
return (If ti represents (v -» ft, Z), return ft.) 

function Apply (®,wi,ii 2 ) : Operator x V x V -+ V 
return (A vertex representing (m ® M2) ) 

function Exists (a;, u) : Var x V -> V 
return (A vertex representing (3x.u).) 

function FullOneSat(u) : V -» V >u^0 
return (A BDD v (fullfilling: v -t u) with exactly one satisfying assignment.) 

function AnySat(u) : V -» (Var x B)-set > u 7^ 0 

return (An assignments satisfying u.) 

function SatCount(w) :F4Z 
return (The number of value assignments for the BDD u.) 

function Min(V) : Var-set -» Var 

return (The variable v in V with lowest ordering: (W € (V - {v}) : v < v').) 

function Max(V) : Var-set -» Var 

return (The variable v in V with highest ordering: (Vv' G (V - {v}) : v' < v).) 
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Algorithm 2 

function MultiApply (<8>, U) : Operator x V-set -4 V > ® associative and commutative 

ifU = {0}then 

return 0 
elsifC7 = {l}then 

return 1 
elsif U = {0,1} then 

return 0 ® 1 
else 

l = MlN({VAR(t7) \v£U}) 

V = {ueU\ Var(w) = »} 
U' = U-V 
L = {Low(u) \ v eV} 
H = {High(i;) \veV} 

return Mk(», MultiApply (®, J? U U'), MultiApply (®, L U C7')) 

fi 



Alg orithm 3 

function MultiExists (X, if) : Var-set xF-»f 
ifu e {0,1} then 

return u 
elsif Var(u) > Max{X) then 

return u 
else 

h = MultiExists (X, High(m)) 
/ = MultiExists (X, Low («)) 
if Var(u) e X then 

return APPLY (V, ft,/) 
else 

return Mk(Var(u), ft, /) 

fi 

fi 



Alg orithm 4 

function OrderRules((i>i, . ..,v n ),E): 

FlatVar-list x (FlatVar x Rule x FlatVar)-set -» (Rule) -set-list 

for i <- 1 to 7Z. do 

-Ej = {(wi, r, tu 2 ) G I (wi = Vi V w 2 = «j)} 
E — F] — .Eg 

i ? i = {r | (wi,^^) G^i} 
end 

return {Fi,...,F n ) 
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Algo rithm 5 _ 

function ConjoinExistsCK,...,^},^,...,^)^) : (Var-set)-list x (V-set)-list x V -> V 

> Vi, 3 € {1, ...,«}: (» < 3 =» i v i n freevars{Fj) = 0)) 

for i f- 1 to n do 

u = MultiApply(A, {w} U Pi) 
u = MultiExists (vf ,«) 
end 

return u 



Algorithm 6 . 

function VirtualizeTable (T,Y) : Table x SymbolTable -> V 

U<r-0 

foreach row % in T 

V 4- 1 

foreach column j in T 

to -f- ViRTUALIZECELL(T,«, j, Y) 

w 4- Apply(A,i7,w) 
end 

u «- Apply(V,u,d) 
end 

return u 

function VirtualizeCell (T, i, j, r ) : Table x Row x Column x SymbolTable -* V 

return (a BDD representing x) = yj, x) is the cell at (row i, column j), yj is the label of column j.) 



Algorithm 7 

function ConfigI (C actual , (v,d),Y) : V x (FlatVar x FlatVal) x SymbolTable V 

u <- (A BDD representing the selection (u = d).) 
return Apply(A, C ac tuah u) 



Algorithm 8 

function CONFIGCONSISTENT(Cbasic>Snew,5' r ) = 

V x (FlatVar x FlatVal)-list x SymbolTable -» 7 

Cactual *~ Cbasic 
foreach s £ S nev! 

Cactual <- CONFIG l(C actua l,S,y) 
end 

return C act uai 
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Algorithm 9 

function CONFiGCHECK(C , basic ,5 ne w,^) : V x (FlatVar x PlatVal)-list x SymbolTable -* 

(V x (FlatVar x FlatVal)-list x (FlatVar x Flat Val) -list) 

Cactual +~ Cbasic 
^actual *~ () 
^rejected 4~ (} 

foreach s e 5 new > Must be "in-order" traversal, 

if CONFIG 1 (Sactual, s, Y) ^ 0 then 
Cactual <~ CONFIGl (S actua l, 
^actual *~ ^actual s 

else 

^rejected ^~ ^rejected ^ 

fi 
end 

return (C ac t U al) <S a ctuab ^rejected) 



Algorithm 10 

function CONFlGlT((7 basic ,5 n ewT) : V x (FlatVar x FlatVal)-list x SymbolTable -> 

(V x (FlatVar x FlatVal)-list) 

> S new must be consistent wrt. to Cc b asic- 

Cactual <~ CONFIGCONSISTENT(C bas ic,5'new,^) 

> C^tual # 0 

Cactual <~ FULLONESAT (Cactual) 
^tual <" ANYSAT(C actua i) 

^actual <- (Victual translated to flattened variable selections by "backwards" use of Y.) 
return (Cactual) ^actual) 



Algorithm 11 

function ConfigCount(u) : V x Symboltable -4 Z 
return SatCount(u) 



Algorithm 12 

function DETERMINEDOMAIN (Cactual i Vi, {vi,... v n }, Y) : 

V x FlatVar x FlatVar-set x SymbolTable -» FlatVal-set 

X <- V? U • • • U 

X^X-vf 

U <- MULTlEXISTS(X, C^tual) 

Z> B -f- (The set of assignments of the Boolean variables v\ in the BDD u.) 

D <- (D B translated to flattened values by "backwards" use of the symbol table Y.) 

return D 
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Algori thm 13 . . 

function ConfioClient({«i, . . . v n }) : FlatVar-set -»■ (FlatVar x FlatVal)-set 

Send (Conf ig, ()) 

repeat 

RECEIVE (Actual, Rejected, N, { D U ■ ■ • > D n)) 

I <r- SHOWSTATUSANDREADFROMUSER(5actual) ^rejected, N,(vi,... V n ), (-Dl, • • • , D n )) 

if J = select(w, d) then > Vi G {1, . . . , n}.((« = « 4 ) (d € A)) 

SEND(Conf ig, STRIPSELECTION(5 actua l,u)' V (v, d)) 

elsif I = Force(u,d) then 

SEND(Config, (t7,drSTRIPSELECTION(5 actua l, v)) 

elsif 7 = Deselect(v) then 

Send (Conf ig, Strip Selection (5 actU ai ,v)) 
elsif / = Reset then 

SEND(Conf ig, ()) 
elsif J = PreConf igure(5 new ) tnen 

SEND(Conf 

elsif J = Conf iglt then 

SEND(Conf iglt, S a ctuai) 
e j se > The selection must be complete. 

return 5 actual > If we S et here: J = sto P' 

fi 
end 

(Unspecified functions: ShowStatusAndReadFromUser, Send, Receive) 

function StripSelection(S» : 

(FlatVar x FlatVal)-list x FlatVar -> (FlatVar x FlatVal)-list 
return (5 modified so that a possible selection relating to the variable v is removed.) 



Algorithm 14 

function CONFlGSERVER(C basi c, {v!, . . . v n },Y) : V x FlatVar-set x SymbolTable -> ? 
repeat 

Receive (C,5 ne w) 
if G = Conf ig then 

(CactuabS'actual, ^rejected) <~ CONFIGCHECK.(Cbasic> <Snewi ^) 
else 

(Cactuai, Actual) <- CONFiGlT(C basic , 5 ne w, Y) > If we get here: C = Conf iglt. 

^rejected {) 
end 

N «- CONFIGCOUNT(C ac tual) 

for i <- 1 to n do 

4- DETERMINEDOMAIN(Cactual: ^ {f 1) • ■ • «n}> 

end 

SEND(5 actual , 5 re jected, N,{D 1: ..., £>„)) 

end 



(Unspecified functions: Send, Receive) 
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